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EXAMINER'S ANSWER 



This is in response to the appeal brief filed 9/13/2007 appealing from the Office action mailed 
8/28/2006. 
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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial proceedings 
which will directly affect or be directly affected by or have a bearing on the Board's decision in 
the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained in 
the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

SyncML Meta-Information DTD, version 1.1, Feb. 15, 2002, published on the Internet, by 
Ericsson, IBM, et al. 

SyncML Representation Protocol, version 1.1, Feb. 15, 2002, published on the Internet, by 
Ericsson, IBM, et al. 
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SyncML Sync Protocol, version 1.1, Feb. 15, 2002, published on the Internet, by Ericsson, IBM, 
et al. 

SyncML Device Management Protocol, version 1.1, Feb. 15, 2002, published on the Internet, by 
Ericsson, IBM et al. 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

1 . Claims 1-6 and 8-30 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Applicant Admitted Prior Art in the application's specification (hereinafter AAPA), in reference 
to SyncML Initiative (including standards and specifications for SyncML Meta-Information, 
SyncML Representation Protocol, and SyncML Sync Protocol, SyncML Device Management 
Protocol). 

2. As per claim 1 , AAPA taught the invention substantially as claimed including a method, 
comprising: 

a. A first device preparing a message including information indicating a folder 

useable for storing data in a data store of the first device (applicant's specification 
page 5, lines 28-34, page 6, lines 1-24, page 7, lines 8-12), wherein the message 
includes a header and a body, each in turn comprising one or more elements, with 
the body element useable for providing commands in connection with 
synchronizing the first data stored with respect to a data store in another device 
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and also useable for conveying data from the data store (page 1, lines 17-24, page 
6, lines 12-18); and 

b. The first device sending the message to the other device (page 5, line 32-34, page 
6, lines 1-24, page 9, lines 21-24). 

3. As per claims 15 and 25, AAPA taught the invention substantially as claimed including a 
device, comprising: 

a. A data store, for storing folders useable for storing data (applicant's specification 
page 1, lines 24-30, page 5, lines 23-24); and 

b. Means for preparing a message including information indicating a folder in the 
data store (page 5, lines 28-34, page 6, lines 1-24, page 7, lines 8-12), wherein the 
message includes a header and a body, each in turn comprising one or more 
elements, with the body elements useable for providing commends in connection 
with synchronizing the data store with respect to another data store in a second 
device and also useable for conveying data from the data store (page 1, lines 17- 
24, page 6, lines 12-18). 

4. AAPA did not specifically teach that said information indicating the folder of the data 
store uniquely identifies the folder and is placed in the message in an element different from 
where data of the data store is placed or would be placed if included in the message. However, 
SyncML Initiative taught that the information indicating the folder of the data store uniquely 
identifies the folder and is placed in the message in an element different from where data of the 
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data store is placed (part of the standard, SyncML Representation Protocol. SyncML Sync 
Protocol: Sync Initialization). It would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of AAPA and SyncML Initiative since 
applicant's disclosure doe not vary from the SyncML Initiative (including standards and 
specifications for SyncML, SyncML Representation Protocol, and SyncML Sync Protocol, 
SyncML Device Management Protocol). The SyncML Message is an individual XML document 
consisting of one or more elements each of one or more element types. The document consists 
of a header, specified by the SyncHdr element type, and a body, specified by the SyncBody 
element type. The SyncML header specifies routing and versioning information about the 
SyncML Message. The SyncML body is a container for one or more SyncML Commands. The 
SyncML Commands are specified by individual element types. The SyncML Commands act as 
containers of other element types that describe the specifics of the SyncML command, including 
any data or meta-information. It is obvious that the data and meta-information are placed in 
different location in the message (see SyncML Sync Protocol: Sync Initialization: Alert 
command for authentication and indication of which folder to be synchronized and Put and Get 
commands for conveying the data). Furthermore, it would have been obvious to combine the 
teachings of AAPA and SyncML Initiative since applications admitted that SyncML is an open 
industry standard for a common language for universal synchronization of remote data for 
synchronizing data stored and transferring management actions (see applicant's specification 
page 2, lines 10-34, page 3, lines 1-19, page 4, lines 3-7, page 6, lines 12-34, page 7, lines 1-25). 
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5. As per claim 2, AAPA further disclosed the element where the information indicating the 
folder is placed in a field of the message (part of the standard, SyncML Representation Protocol). 

6. As per claim 3, AAPA further disclosed data of the data store is placed or would be 
placed in a data element of the message (applicant's specification page 7, lines 18-25, page 8, 
lines 30-34, page 9, lines 1-7, it is obvious that a data, if it would be place, would be placed in a 
data element). 

7. As per claim 4, AAPA further disclosed that the data element is a data element of a 
protocol command element (applicant's specification page 7, lines 18-25, page 9, lines 12-17). 

8. As per claims 5-6, AAPA further disclosed the information indicating the folder is 
included in a non-data element of the message and wherein the non-data element is a non-data 
element of a protocol command element (applicant's specification page 9, lines 12-17, it is also 
obvious within the SyncML Representation Protocol that "meta-data" would be placed in a non- 
data element). 

9. As per claim 8, AAPA further disclosed a data identification element is contained in a 
protocol command element in the message, and the protocol command element in combination 
with the data identification element indicates the folder of the data store of the first device 
(applicant's specification page 7, lines 8-14, page 9, lines 8-11, it is also obvious within the 
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SyncML Representation Protocol that the SyncML message contains the SyncML command, as 
well as the related data and meta-information). 

10. As per claim 9, AAPA further disclosed a data identification element is included in the 
message and the information indicating the folder of the data store of the first device is provided 
in the data identification element (applicant's specification page 6, lines 02-24, page 7, lines 8- 
14, page 9, lines 21-24, it is also obvious within the SyncML Representation Protocol that the 
SyncML message contains the SyncML command, as well as the related data and meta- 
information). 

11. As per claim 10, AAPA further disclosed that the first device functions as a client in a 
client-server protocol and the second device as a server in the client-server protocol (applicant's 
specification page 1, lines 17-34, page 2, lines 1-9). 

12. As per claim 11, AAPA further disclosed the first device functions as a server in a client- 
server protocol and the second deice as a client in the client-server protocol, and in preparing the 
message the first device is responsive to a client message form the second device and includes 
resolving any conflicts posed by the client message in respect to the data stored of the first 
device (applicant's specification page 1, lines 17-34, page 2, lines 1-9). 
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13. As per claim 12, AAPA further disclosed the data in the data stores are for device 
management by applications hosted on the devices (applicant's specification page 2, lines 30-33, 
SyncML device management protocol). 

14. As per claim 13, AAPA further disclosed the data in the data stores are used as user data 
by applications hosted on the devices (applicant's specification page 1, lines 31-34, page 2, lines 
1-9). 

15. As per claim 14, AAPA and SyncML Initiative inherently disclosed a computer program 
product comprising: a computer readable storage structure embodying computer program code 
thereon for execution by a computer processor, with said computer program code characterized 
in that it includes instructions for performing the steps of the method of claim 1. 

16. As per claims 16 and 26, AAPA further disclosed that the device is either a wireless 
communication or a wireline communication terminal (applicant's specification page 1, lines 17- 
24, page 2, lines 21-29). 

1 7. As per claims 1 7 and 27, AAPA further disclosed that the device is configured to 
function as a client in a client-server model (applicant's specification page 1, lines 17-30). 

1 8. As per claims 1 8 and 28, AAPA further disclosed that the device is configured to 
function as a server in a client-server model, and further comprises means for receiving a request 
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to synchronize from the second device, and for then sending the message in response to the 
request to synchronize (part of sync SyncML protocol). 

19. As per claims 19 and 29, AAPA further disclosed that further comprising means for 
receiving form the second device a message including information indicating a folder in the other 
data store, wherein the message includes a header and a body, each in turn comprising one or 
more elements, with the body elements useable for providing commands in connection with 
synchronizing the other data store with respect to the data store in the device and also useable for 
conveying data form the other data store (applicant's specification page 1, lines 17-24, page 5, 
lines 28-34, page 6, lines 1-24, page 7, lines 8-12), and wherein the device is configured to 
function as a server in a client-server model and includes means for resolving conflicts posed by 
the message (applicant's specification page 1, lines 17-34, page 2, lines 1-9). 

20. As per claims 20 and 30, AAPA further disclosed that the data in the data store is used 
for device management by applications hosted on the device (applicant's specification page 2, 
lines 30-33, SyncML device management protocol). 

21. As per claim 2 1 , AAPA further disclosed that the data in the data store is used as user 
data by applications hosted by the device (applicant's specification page 1, lines 31-34, page 2, 
lines 1-9). 
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22. As per claim 22, AAPA disclosed a system, comprising a device according to claim 15, 
and also comprising the second device hosting the other data store (applicant's specification page 
1, liens 17-34, page 2, lines 1-9). 

23. As per claim 23, AAPA further disclosed that the device is configured to function as a 
server in a client-server model and the second device functions as a client in the client-server 
model (applicant's specification page 1, liens 17-34, page 2, lines 1-9). 

24. As per claim 24, AAPA further disclosed that the device is configured to send the 
message to the second device in response to a request sent by the second device to synchronize 
to the second device (part of sync SyncML protocol). 

(10) Response to Argument 

The examiner summarizes the various points raised by the appellant and addresses replies 
individually. 

As per appellant's argument that: 

(1) a "database" cannot be understood as a "folder". 

In reply to (1): Where applicant acts as his or her own lexicographer to specifically define 
a term of a claim contrary to its ordinary meaning, the written description must clearly redefine 
the claim term and set forth the uncommon definition so as to put one reasonably skilled in the 
art on notice that the appellant intended to so redefine that claim term. Process Control Corp. v. 
HydReclaim Corp., 190 F.3d 1350, 1357, 52 USPQ2d 1029, 1033 (Fed. Cir. 1999). The term 
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"folder" in the claims is used by the claim to mean "one folder in a set of folders", "one record in 

a set of records", or "one filed in a set of fields", while the accepted meaning is "a container for 

programs and files which is also called directory in various systems." The term is very broad 

because the specification provides multiple definitions and examples in showing what a "folder" 

can be. See page 1 1-12 of the appeal brief. 

Page 5, lines 28-31 of appellant's specification further stated: 

It is important to understand that the term folder is thus used expansively, to 
indicate any container of data units, and the terminology directory structure or data 
structure has a correspondingly expansive meaning. 

. Accordingly, a "database" falls into the appellant's definition of "folder" since a database 
is included in the definition of "any container of data units" as defined in page 5, lines 28-31 of 
appellant's specification. 

Further, a database comprising nothing but one record or a database with no more than 
one directory is functionally identical to a folder. 

(2) SyncML teaches using the Alert command in a data element portion of a SyncML 
message, not in a non-data element as required by the claims, "wherein said information 
indicating the folder of the data store uniquely identifies the folder and is placed in the message 
in an element different from where data of the data store is placed or would be placed if included 
in the message". 



In reply to (2): AAPA taught a SyncML message including information indicating a 
folder useable for storing data in a data store of the first device (page 5, lines 28-34, page 6, lines 



Application/Control Number: 10/781,325 Page 12 

Art Unit: 2152 

1-24, page 7, lines 8-12). The SyncML Message is an individual XML document consisting of 
one or more elements each of one or more element types. The document consists of a header, 
specified by the SyncHdr element type, and a body, specified by the SyncBody element type. 
The SyncML header specifies routing and versioning information about the SyncML Message. 
The SyncML body is a container for one or more SyncML Commands. The SyncML 
Commands are specified by individual element types. The SyncML Commands act as containers 
of other element types that describe the specifics of the SyncML command, including any data or 
meta-information. It is obvious that the data and meta-information are placed in different 
location in the message (see SyncML Sync Protocol: 4 Sync Initialization: Alert command for 
authentication and indication of which folder to be synchronized and Put and Get commands for 
conveying the data. Page 27-34: Note that data element and meta element in Alert command is 
separated in the SyncML message example of 4.1.1 and 4.2.1). Furthermore, it would have been 
obvious to combine the teachings of AAPA and SyncML Initiative since applications admitted 
that SyncML is an open industry standard for a common language for universal synchronization 
of remote data for synchronizing data stored and transferring management actions (see page 2, 
lines 10-34, page 3, lines 1-19, page 4, lines 3-7, page 6, lines 12-34, page 7, lines 1-25). 

Session 4, Sync Initialization of SyncML Sync Protocol of SyncML Initiative shows the 
use of Alert command (e.g. element) for authentication and indication of which database to be 
synchronized and Put and Get commands (e.g. different elements from Alert command) for 
conveying the data. Note that data element field and meta element field in Alert command is 
separated in the SyncML message example of 4.1.1 and 4.2.1 with location identifiers separated 
from the data element field. This clearly shows the claimed limitation of "information indicating 
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the folder of the data store uniquely identifies the folder and is placed in the message in an 
element different from where data of the data store is placed or would be placed if included in 
the message". 



(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the Related 
Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be sustained. 

Respectfully submitted, 

ksl 
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/Lynne H Browne/ 

Lynne H Browne 

Appeal Practice Specialist, TQAS 

Technology Center 2100 




